home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / networking / 3327 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.0 KB
  1. Path: walrus.megabaud.fi!not-for-mail
  2. From: petrin@walrus.megabaud.fi (Petri Nordlund)
  3. Newsgroups: comp.sys.amiga.networking
  4. Subject: Re: Announce: AWeb 1.0 released!
  5. Date: 1 Apr 1996 17:15:07 +0300
  6. Organization: Megabaud Oy,Helsinki,Finland
  7. Message-ID: <4joodb$74d@walrus.megabaud.fi>
  8. NNTP-Posting-Host: walrus.megabaud.fi
  9.  
  10. Michael van Elst (mlelstv@serpens.rhein.de) writes:
  11. >petrin@walrus.megabaud.fi (Petri Nordlund) writes:
  12. >>>That's something that you do not want. You want I/O, decoding and
  13. >>>rendering done concurrently and this means: at the same priority so
  14. >>>that they are timesliced.
  15. >
  16. >>  I don't think that would be a good idea. You don't want image decoding
  17. >>  to slow down rendering or response to GUI events. The magic word here
  18. >>  is: threads.
  19. >
  20. >Where is the problem with decoding "slowing down" rendering ? The total
  21. >time is the same and concurrent operation will give a wanted visual
  22. >progress.
  23.  
  24.   If rendering just means drawing the decoded images, then it
  25.   doesn't matter. But things like scrolling the document and
  26.   opening other windows like hotlists etc. must not be slowed
  27.   down by this.
  28.  
  29. >I also didn't say anything about "response to GUI events". I/O means
  30. >network I/O. Sorry, if that was confusing.
  31.  
  32.   Ok, but why should rendering and decoding slow down network I/O?
  33.  
  34. >>  The best way to implement a WWW browser would be to use threads with
  35. >>  fixed priorities.
  36. >
  37. >That's what AWeb does, although it runs the threads at the same fixed
  38. >priority of 0.
  39.  
  40.   Which doesn't make much sense because image decoding slows down
  41.   everything else. You must remember that when the decoder task
  42.   is running and you click on a gadget, the main task is not
  43.   waked up immediately, Exec will let the decoder task run for
  44.   a full quantum. The result is that the main task gets LESS
  45.   than 50% of available CPU time to handle the GUI and user input.
  46.  
  47. >>     3 rendering
  48. >>     2 decoder (small images)
  49. >>     1 decoder (large images)
  50. >
  51. >And this is something you do not need. Why should rendering stop decoding ?
  52.  
  53.   Let's say you are scrolling the display, why should decoding make
  54.   scrolling slower?
  55.  
  56. >>  You can implement this on Amiga, but it doesn't work with dynamic
  57. >>  priorities. If we would have threads on Amiga, there would be only
  58. >>  one task to be scheduled.
  59. >
  60. >We have threads, thank you. And no, most systems schedule threads.
  61.  
  62.   We have LWPs (Light-Weight Processes), not real threads.
  63.   We need user-level threads run as a single process. All threads
  64.   share the same address space and are scheduled by a selectable
  65.   thread-scheduler. Now we can only guess what would be good
  66.   priorities for different LWPs, hoping that the main task is
  67.   always run at priority 0.
  68.  
  69.   And if AT decides to bring Amiga OS and multitasking up-to-date,
  70.   we need threads, either OS supported or as a 3rd party shared
  71.   thread-library.
  72. -- 
  73.                                       __
  74.  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~///~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  75.        Petri Nordlund             __///         petrin@megabaud.fi
  76.  ---------------------------------\XX/----------------------------------
  77.